WebAssembly Host Bindings: Sömlös integration med körtidsmiljöer

WebAssembly (WASM) har snabbt utvecklats från att vara en teknik enbart för webbläsare till en universell körtidslösning. Dess löfte om hög prestanda, portabilitet och säkerhet gör det till ett attraktivt val för en mängd olika applikationer, från serverlösa funktioner till inbyggda system. Men för att WASM verkligen ska kunna frigöra sin potential måste det kunna interagera sömlöst med värdmiljön – det program eller system som kör WASM-modulen. Det är här WebAssembly Host Bindings (värdbindningar) spelar en avgörande roll.

I denna omfattande guide kommer vi att djupdyka i detaljerna kring WebAssembly host bindings, utforska vad de är, varför de är nödvändiga och hur de möjliggör en robust integration mellan WASM-moduler och deras olika körtidsmiljöer. Vi kommer att granska olika tillvägagångssätt, belysa verkliga användningsfall och ge praktiska insikter för utvecklare som vill utnyttja denna kraftfulla funktion.

Förståelse för WebAssembly Host Bindings

I grunden är WebAssembly utformat som ett portabelt kompileringsmål för programmeringsspråk. WASM-moduler är i huvudsak fristående kod-enheter som kan exekveras i en sandlådemiljö. Denna sandlåda ger säkerhet som standard och begränsar vad WASM-kod kan göra. De flesta praktiska applikationer kräver dock att WASM-moduler interagerar med omvärlden – för att komma åt systemresurser, kommunicera med andra delar av applikationen eller utnyttja befintliga bibliotek.

Värdbindningar (host bindings), även kända som importerade funktioner eller värdfunktioner, är mekanismen genom vilken en WASM-modul kan anropa funktioner som definieras och tillhandahålls av värdmiljön. Se det som ett kontrakt: WASM-modulen deklarerar att den behöver tillgång till vissa funktioner, och värdmiljön garanterar att de tillhandahålls.

Omvänt kan värdmiljön också anropa funktioner som exporteras av en WASM-modul. Denna dubbelriktade kommunikation är grundläggande för all meningsfull integration.

Varför är värdbindningar nödvändiga?

• Interoperabilitet: Värdbindningar är den bro som gör att WASM-kod kan samverka med värdspråket och dess ekosystem. Utan dem skulle WASM-moduler vara isolerade och oförmögna att utföra vanliga uppgifter som att läsa filer, göra nätverksanrop eller interagera med användargränssnitt.
• Utnyttja befintlig funktionalitet: Utvecklare kan skriva sin kärnlogik i WASM (kanske av prestanda- eller portabilitetsskäl) samtidigt som de utnyttjar de omfattande biblioteken och funktionerna i sin värdmiljö (t.ex. C++-bibliotek, Go:s samtidighetspremitiver eller JavaScripts DOM-manipulation).
• Säkerhet och kontroll: Värdmiljön bestämmer vilka funktioner som exponeras för WASM-modulen. Detta ger en finkornig kontroll över de förmågor som ges till WASM-koden, vilket förbättrar säkerheten genom att endast exponera nödvändig funktionalitet.
• Prestandaoptimeringar: För beräkningsintensiva uppgifter kan det vara mycket fördelaktigt att avlasta dem till WASM. Dessa uppgifter behöver dock ofta interagera med värden för I/O eller andra operationer. Värdbindningar underlättar detta effektiva datautbyte och delegering av uppgifter.
• Portabilitet: Även om WASM i sig är portabelt, kan sättet det interagerar med värdmiljön variera. Väl utformade gränssnitt för värdbindningar syftar till att abstrahera bort dessa värdspecifika detaljer, vilket gör att WASM-moduler lättare kan återanvändas i olika körtidsmiljöer.

Vanliga mönster och tillvägagångssätt för värdbindningar

Implementeringen av värdbindningar kan variera beroende på WebAssembly-körtiden och de inblandade språken. Flera vanliga mönster har dock utkristalliserats:

1. Explicita funktionsimporter

Detta är det mest grundläggande tillvägagångssättet. WASM-modulen listar explicit de funktioner den förväntar sig att importera från värden. Värdmiljön tillhandahåller sedan implementationer för dessa importerade funktioner.

Exempel: En WASM-modul skriven i Rust kan importera en funktion som console_log(message: *const u8, len: usize) från värden. Värden, i detta fall JavaScript-miljön, skulle då tillhandahålla en funktion med namnet console_log som tar en pekare och en längd, avrefererar minnet på den adressen och anropar JavaScripts console.log.

Nyckelaspekter:

• Typsäkerhet: Signaturen för den importerade funktionen (namn, argumenttyper, returtyper) måste matcha värdens implementation.
• Minneshantering: Data som skickas mellan WASM-modulen och värden ligger ofta i WASM-modulens linjära minne. Bindningar måste hantera läsning från och skrivning till detta minne på ett säkert sätt.

2. Indirekta funktionsanrop (funktionspekare)

Utöver direkta funktionsimporter tillåter WASM att värden skickar funktionspekare (eller referenser) som argument till WASM-funktioner. Detta gör att WASM-kod dynamiskt kan anropa funktioner som tillhandahålls av värden vid körtid.

Exempel: En WASM-modul kan ta emot en callback-funktionspekare för händelsehantering. När en händelse inträffar inuti WASM-modulen kan den anropa denna callback och skicka relevant data tillbaka till värden.

Nyckelaspekter:

• Flexibilitet: Möjliggör mer dynamiska och komplexa interaktioner än direkta importer.
• Overhead: Kan ibland introducera en liten prestanda-overhead jämfört med direkta anrop.

3. WASI (WebAssembly System Interface)

WASI är ett modulärt systemgränssnitt för WebAssembly, utformat för att göra det möjligt för WASM att köras utanför webbläsaren på ett säkert och portabelt sätt. Det definierar en standardiserad uppsättning API:er som WASM-moduler kan importera, vilka täcker vanliga systemfunktioner som fil-I/O, nätverk, klockor och generering av slumptal.

Exempel: Istället för att importera anpassade funktioner för att läsa filer, kan en WASM-modul importera funktioner som fd_read eller path_open från modulen wasi_snapshot_preview1. WASM-körtiden tillhandahåller sedan implementeringen för dessa WASI-funktioner, ofta genom att översätta dem till native systemanrop.

Nyckelaspekter:

• Standardisering: Syftar till att tillhandahålla ett konsekvent API över olika WASM-körtider och värdmiljöer.
• Säkerhet: WASI är utformat med säkerhet och kapabilitetsbaserad åtkomstkontroll i åtanke.
• Ekosystem i utveckling: WASI är fortfarande under aktiv utveckling, med nya moduler och funktioner som läggs till.

4. Körtidsspecifika API:er och bibliotek

Många WebAssembly-körtider (som Wasmtime, Wasmer, WAMR, Wazero) tillhandahåller sina egna högnivå-API:er och bibliotek för att förenkla skapandet och hanteringen av värdbindningar. Dessa abstraherar ofta bort de lågnivådetaljer som rör WASM:s minneshantering och matchning av funktionssignaturer.

Exempel: En Rust-utvecklare som använder wasmtime-kraten kan använda attributen #[wasmtime_rust::async_trait] och #[wasmtime_rust::component] för att definiera värdfunktioner och komponenter med minimal boilerplate. På liknande sätt tillhandahåller wasmer-sdk i Rust eller wasmer-interface-types i olika språk verktyg för att definiera gränssnitt och generera bindningar.

Nyckelaspekter:

• Utvecklarupplevelse: Förbättrar avsevärt användarvänligheten och minskar risken för fel.
• Effektivitet: Ofta optimerade för prestanda inom sin specifika körtid.
• Leverantörsinlåsning: Kan binda din implementation närmare en specifik körtid.

Integrera WASM med olika värdmiljöer

Kraften i WebAssembly host bindings blir som tydligast när vi ser hur WASM kan integreras med olika värdmiljöer. Låt oss utforska några framstående exempel:

1. Webbläsare (JavaScript som värd)

Detta är WebAssemblys födelseplats. I webbläsaren agerar JavaScript som värd. WASM-moduler laddas och instansieras med hjälp av WebAssembly JavaScript API.

• Bindningar: JavaScript tillhandahåller importerade funktioner till WASM-modulen. Detta görs ofta genom att skapa ett WebAssembly.Imports-objekt.
• Datautbyte: WASM-moduler har sitt eget linjära minne. JavaScript kan komma åt detta minne med hjälp av WebAssembly.Memory-objekt för att läsa/skriva data. Bibliotek som wasm-bindgen automatiserar den komplexa processen att skicka komplexa datatyper (strängar, objekt, arrayer) mellan JavaScript och WASM.
• Användningsfall: Spelutveckling (Unity, Godot), multimediabearbetning, beräkningsintensiva uppgifter i webbapplikationer, ersättning av prestandakritiska JavaScript-moduler.

Globalt exempel: Tänk dig en webbapplikation för fotoredigering. En beräkningsintensiv bildfiltreringsalgoritm kan skrivas i C++ och kompileras till WASM. JavaScript skulle ladda WASM-modulen, tillhandahålla en process_image-värdfunktion som tar emot bilddata (kanske som en byte-array i WASM-minnet) och sedan visa den bearbetade bilden för användaren.

2. Server-side-körtider (t.ex. Node.js, Deno)

Att köra WASM utanför webbläsaren öppnar upp ett helt nytt landskap. Node.js och Deno är populära JavaScript-körtider som kan agera värd för WASM-moduler.

• Bindningar: Liksom i webbläsarmiljöer kan JavaScript i Node.js eller Deno tillhandahålla importerade funktioner. Körtider har ofta inbyggt stöd eller moduler för att ladda och interagera med WASM.
• Åtkomst till systemresurser: WASM-moduler som körs på servern kan ges åtkomst till värdens filsystem, nätverkssocketer och andra systemresurser via noggrant utformade värdbindningar. WASI är särskilt relevant här.
• Användningsfall: Utöka Node.js med högpresterande moduler, köra opålitlig kod säkert, edge computing-distributioner, mikrotjänster.

Globalt exempel: En global e-handelsplattform kan använda Node.js för sin backend. För att hantera betalningshantering säkert och effektivt kan en kritisk modul skrivas i Rust och kompileras till WASM. Denna WASM-modul skulle importera funktioner från Node.js för att interagera med en säker hårdvarusäkerhetsmodul (HSM) eller för att utföra kryptografiska operationer, vilket säkerställer att känslig data aldrig lämnar WASM-sandlådan eller hanteras av betrodda värdfunktioner.

3. Nativa applikationer (t.ex. C++, Go, Rust)

WebAssembly-körtider som Wasmtime och Wasmer är inbäddningsbara i nativa applikationer skrivna i språk som C++, Go och Rust. Detta gör att utvecklare kan integrera WASM-moduler i befintliga C++-applikationer, Go-tjänster eller Rust-demoner.

• Bindningar: Det inbäddande språket tillhandahåller värdfunktioner. Körtider erbjuder API:er för att definiera dessa funktioner och skicka dem till WASM-instansen.
• Datautbyte: Effektiva mekanismer för dataöverföring är avgörande. Körtider tillhandahåller sätt att mappa WASM-minne och anropa WASM-funktioner från värdspråket, och vice versa.
• Användningsfall: Pluginsystem, sandlådehantering av opålitlig kod i en nativ applikation, köra kod skriven i ett språk inuti en applikation skriven i ett annat, serverlösa plattformar, inbyggda enheter.

Globalt exempel: Ett stort multinationellt företag som utvecklar en ny IoT-plattform kan använda ett Rust-baserat inbyggt Linux-system. De skulle kunna använda WebAssembly för att distribuera och uppdatera logik på edge-enheter. Den centrala Rust-applikationen skulle agera som värd och tillhandahålla värdbindningar till WASM-moduler (kompilerade från olika språk som Python eller Lua) för sensordatabehandling, enhetskontroll och lokalt beslutsfattande. Detta ger flexibilitet att välja det bästa språket för specifika enhetsuppgifter samtidigt som en säker och uppdaterbar körtid bibehålls.

4. Serverless och Edge Computing

Serverlösa plattformar och edge computing-miljöer är utmärkta kandidater för WebAssembly på grund av dess snabba starttider, lilla fotavtryck och säkerhetsisolering.

• Bindningar: Serverlösa plattformar tillhandahåller vanligtvis API:er för att interagera med deras tjänster (t.ex. databaser, meddelandeköer, autentisering). Dessa exponeras som importerade WASM-funktioner. WASI är ofta den underliggande mekanismen för dessa integrationer.
• Användningsfall: Köra backend-logik utan att hantera servrar, edge-funktioner för databehandling med låg latens, logik för content delivery network (CDN), IoT-enhetshantering.

Globalt exempel: En global streamingtjänst skulle kunna använda WASM-baserade funktioner på edge för att anpassa innehållsrekommendationer baserat på användarens plats och visningshistorik. Dessa edge-funktioner, som körs på CDN-servrar över hela världen, skulle importera bindningar för att komma åt cachad användardata och interagera med ett rekommendationsmotor-API, allt medan de drar nytta av WASM:s snabba kallstarter och minimala resursanvändning.

Praktisk implementering: Fallstudier och exempel

Låt oss titta på hur värdbindningar implementeras praktiskt med populära körtider och språkkombinationer.

Fallstudie 1: Rust WASM-modul anropar JavaScript-funktioner

Detta är ett vanligt scenario för webbutveckling. Verktygskedjan wasm-bindgen är avgörande här.

Rust-kod (i din `.rs`-fil):

            
// Deklarera funktionen vi förväntar oss från JavaScript
#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

            

              
                Copy
              
            
          

JavaScript-kod (i din HTML- eller `.js`-fil):

            
// Importera WASM-modulen
import init, { greet } from './pkg/my_wasm_module.js';

async function run() {
  await init(); // Initialisera WASM-modulen
  greet("World"); // Anropa den exporterade WASM-funktionen
}

run();

            

              
                Copy
              
            
          

Förklaring:

• extern "C"-blocket i Rust deklarerar funktioner som kommer att importeras från värden. #[wasm_bindgen] används för att markera dessa och andra funktioner för sömlös interoperabilitet.
• wasm-bindgen genererar den nödvändiga JavaScript-limkoden och hanterar den komplexa data-marshallingen mellan Rust (kompilerat till WASM) och JavaScript.

Fallstudie 2: Go-applikation agerar värd för en WASM-modul med WASI

Använder wasi_ext (eller liknande) Go-paket med en WASM-körtid som Wasmtime.

Go-värdkod:

            
package main

import (
    "fmt"
    "os"

    "github.com/bytecodealliance/wasmtime-go"
)

func main() {
    // Skapa en ny runtime-länkare
    linker := wasmtime.NewLinker(wasmtime.NewStore(nil))

    // Definiera WASI preview1-kapabiliteter (t.ex. stdio, klockor)
    wasiConfig := wasmtime.NewWasiConfig()
    wasiConfig.SetStdout(os.Stdout)
    wasiConfig.SetStderr(os.Stderr)

    // Skapa en WASI-instans bunden till länkaren
    wasi, _ := wasmtime.NewWasi(linker, wasiConfig)

    // Ladda WASM-modul från fil
    module, _ := wasmtime.NewModuleFromFile(linker.GetStore(), "my_module.wasm")

    // Instansiera WASM-modulen
    instance, _ := linker.Instantiate(module)

    // Hämta WASI-exporten (vanligtvis `_start` eller `main`)
    // Den faktiska startpunkten beror på hur WASM kompilerades
    entryPoint, _ := instance.GetFunc("my_entry_point") // Exempel på startpunkt

    // Anropa WASM-startpunkten
    if entryPoint != nil {
        entryPoint.Call()
    } else {
        fmt.Println("Entry point function not found.")
    }

    // Städa upp WASI-resurser
    wasi.Close()
}

            

              
                Copy
              
            
          

WASM-modul (t.ex. kompilerad från C/Rust med WASI-mål):

WASM-modulen skulle helt enkelt använda standard-WASI-anrop, som att skriva ut till standard output:

            
// Exempel i C kompilerat med --target=wasm32-wasi
#include <stdio.h>

int main() {
    printf("Hello from WebAssembly WASI module!\n");
    return 0;
}

            

              
                Copy
              
            
          

Förklaring:

• Go-värden skapar en Wasmtime store och linker.
• Den konfigurerar WASI-kapabiliteter och mappar standard output/error till Go:s filbeskrivningar.
• WASM-modulen laddas och instansieras, med WASI-funktioner importerade och tillhandahållna av länkaren.
• Go-programmet anropar sedan en exporterad funktion inuti WASM-modulen, som i sin tur använder WASI-funktioner (som fd_write) för att producera utdata.

Fallstudie 3: C++-applikation agerar värd för WASM med anpassade bindningar

Använder en körtid som Wasmer-C-API eller Wasmtimes C-API.

C++-värdkod (konceptuellt exempel med Wasmer C API):

            
#include <wasmer.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Implementering av anpassad värdfunktion
void my_host_log(int message_ptr, int message_len) {
    // Behöver komma åt WASM-minnet här för att hämta strängen
    // Detta kräver hantering av WASM-instansens minne
    printf("[HOST LOG]: "
           "%.*s\n",
           message_len, // Förutsatt att message_len är korrekt
           wasm_instance_memory_buffer(instance, message_ptr, message_len)); // Hypotetisk funktion för minnesåtkomst
}

int main() {
    // Initialisera Wasmer
    wasmer_engine_t* engine = wasmer_engine_new();
    wasmer_store_t* store = wasmer_store_new(engine);

    // Skapa ett Wasmtime linker- eller Wasmer Imports-objekt
    wasmer_imports_t* imports = wasmer_imports_new();

    // Definiera värdfunktionens signatur
    wasmer_func_type_t* func_type = wasmer_func_type_new(
        (wasmer_value_kind_t[]) { WASMER_VALUE_I32 }, // Param 1: pekare (i32)
        1,
        (wasmer_value_kind_t[]) { WASMER_VALUE_I32 }, // Param 2: längd (i32)
        1,
        (wasmer_value_kind_t[]) { WASMER_VALUE_VOID }, // Returtyp: void
        0
    );

    // Skapa en anropbar värdfunktion
    wasmer_func_t* host_func = wasmer_func_new(store, func_type, my_host_log);

    // Lägg till värdfunktionen i importobjektet
    wasmer_imports_define(imports, "env", "log", host_func);

    // Kompilera och instansiera WASM-modulen
    wasmer_module_t* module = NULL;
    wasmer_instance_t* instance = NULL;
    // ... ladda "my_module.wasm" ...
    // ... instansiera instansen med store och imports ...

    // Hämta och anropa en exporterad WASM-funktion
    wasmer_export_t* export = wasmer_instance_exports_get_index(instance, 0); // Förutsatt att första exporten är vårt mål
    wasmer_value_t* result = NULL;
    wasmer_call(export->func, &result);

    // ... hantera resultat och städa upp ...
    wasmer_imports_destroy(imports);
    wasmer_store_destroy(store);
    wasmer_engine_destroy(engine);

    return 0;
}

            

              
                Copy
              
            
          

WASM-modul (kompilerad från C/Rust med en funktion vid namn `log`):

            
// Exempel i C:
extern void log(int message_ptr, int message_len);

void my_wasm_function() {
    const char* message = "This is from WASM!";
    // Behöver skriva meddelandet till WASM:s linjära minne och hämta dess pekare/längd
    // För enkelhetens skull, anta att minneshanteringen är löst.
    int msg_ptr = /* get pointer to message in WASM memory */;
    int msg_len = /* get length of message */;
    log(msg_ptr, msg_len);
}

            

              
                Copy
              
            
          

Förklaring:

• C++-värden definierar en nativ funktion (my_host_log) som kommer att kunna anropas från WASM.
• Den definierar den förväntade signaturen för denna värdfunktion.
• En wasmer_func_t skapas från den nativa funktionen och signaturen.
• Denna wasmer_func_t läggs till i ett importobjekt under ett specifikt modulnamn (t.ex. "env") och funktionsnamn (t.ex. "log").
• När WASM-modulen instansieras importerar den "env":s "log"-funktion.
• När WASM-koden anropar `log` skickar Wasmer-körtiden anropet till C++-funktionen my_host_log och ser till att minnespekare och längder skickas korrekt.

Utmaningar och bästa praxis

Även om värdbindningar erbjuder enorm kraft, finns det utmaningar att ta hänsyn till:

Utmaningar:

• Komplexiteten i data-marshalling: Att skicka komplexa datastrukturer (strängar, arrayer, objekt, anpassade typer) mellan WASM och värden kan vara invecklat, särskilt när det gäller att hantera minnesägarskap och livslängder.
• Prestanda-overhead: Frekventa eller ineffektiva anrop mellan WASM och värden kan skapa prestandaflaskhalsar på grund av kontextbyten och datakopiering.
• Verktyg och felsökning: Felsökning av interaktioner mellan WASM och värden kan vara mer utmanande än att felsöka inom en enskild språkmiljö.
• API-stabilitet: Även om WebAssembly i sig är stabilt, kan mekanismer för värdbindningar och körtidsspecifika API:er utvecklas, vilket kan kräva koduppdateringar. WASI syftar till att mildra detta för systemgränssnitt.
• Säkerhetsaspekter: Att exponera för många värdfunktioner eller dåligt implementerade bindningar kan skapa säkerhetshål.

Bästa praxis:

• Minimera anrop över sandlådegränsen: Batcha operationer där det är möjligt. Istället för att anropa en värdfunktion för varje enskilt objekt i en stor datamängd, skicka hela datamängden på en gång.
• Använd körtidsspecifika verktyg: Utnyttja verktyg som wasm-bindgen (för JavaScript), eller funktionerna för att generera bindningar i körtider som Wasmtime och Wasmer för att automatisera marshalling och minska boilerplate.
• Föredra WASI för systemgränssnitt: När du interagerar med standard-systemfunktioner (fil-I/O, nätverk), föredra WASI-gränssnitt för bättre portabilitet och standardisering.
• Stark typning: Säkerställ att funktionssignaturer mellan WASM och värden matchar exakt. Använd genererade typsäkra bindningar när det är möjligt.
• Noggrann minneshantering: Förstå hur WASM:s linjära minne fungerar. När data skickas, se till att det kopieras eller delas korrekt, och undvik hängande pekare eller åtkomst utanför gränserna.
• Isolera opålitlig kod: Om du kör opålitliga WASM-moduler, se till att de endast beviljas de minimalt nödvändiga värdbindningarna och körs i en strikt kontrollerad miljö.
• Prestandaprofilering: Profilera din applikation för att identifiera flaskhalsar i interaktionen mellan värd och WASM och optimera därefter.

Framtiden för WebAssembly Host Bindings

WebAssembly-landskapet utvecklas ständigt. Flera nyckelområden formar framtiden för värdbindningar:

• WebAssembly Component Model: Detta är en betydande utveckling som syftar till att tillhandahålla ett mer strukturerat och standardiserat sätt för WASM-moduler att interagera med varandra och med värden. Det introducerar koncept som gränssnitt och komponenter, vilket gör bindningar mer deklarativa och robusta. Denna modell är utformad för att vara språkagnostisk och fungera över olika körtider.
• WASI-evolution: WASI fortsätter att mogna, med förslag på nya kapabiliteter och förfiningar av befintliga. Detta kommer att ytterligare standardisera systeminteraktioner, vilket gör WASM ännu mer mångsidigt för miljöer utanför webbläsaren.
• Förbättrade verktyg: Förvänta dig fortsatta framsteg inom verktyg för att generera bindningar, felsöka WASM-applikationer och hantera beroenden mellan WASM och värdmiljöer.
• WASM som ett universellt pluginsystem: Kombinationen av WASM:s sandlådehantering, portabilitet och värdbindningskapabiliteter positionerar det som en idealisk lösning för att bygga utbyggbara applikationer, vilket gör att utvecklare enkelt kan lägga till nya funktioner eller integrera tredjepartslogik.

Slutsats

WebAssembly host bindings är nyckeln för att frigöra WebAssemblys fulla potential bortom dess ursprungliga webbläsarkontext. De möjliggör sömlös kommunikation och datautbyte mellan WASM-moduler och deras värdmiljöer, vilket underlättar kraftfulla integrationer över olika plattformar och språk. Oavsett om du utvecklar för webben, server-side-applikationer, inbyggda system eller edge computing, är förståelse och effektiv användning av värdbindningar avgörande för att bygga högpresterande, säkra och portabla applikationer.

Genom att anamma bästa praxis, utnyttja moderna verktyg och hålla ett öga på framväxande standarder som Component Model och WASI, kan utvecklare utnyttja kraften i WebAssembly för att skapa nästa generations mjukvara, och verkligen göra det möjligt för kod att köras var som helst, säkert och effektivt.

Redo att integrera WebAssembly i dina projekt? Börja utforska värdbindningsmöjligheterna i din valda körtid och språk idag!